Compliance Assessments of Projects Adhering to Enterprise Architecture

This article examines how to assess projects, which implement business processes and IT systems, on compliance with an Enterprise Architecture (EA) that provides them with constraints and high-level solutions. The authors begin by presenting the core elements of EA compliance testing. Next, the authors discuss the testing process and four types of compliance checks (i.e., correctness check, justification check, consistency check, and completeness check). Finally, an empirical case is reported in which a real-life project has been tested on conformance, demonstrating and evaluating the authors’ approach. The results indicate that objective compliance testing cannot be taken for granted. Therefore, several suggestions are presented to decrease the subjectivity of assessments, such as operationalization of EA prescriptions. DOI: 10.4018/jdm.2012040103 Journal of Database Management, 23(2), 44-71, April-June 2012 45 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. thuis et al., 2008; Hoogervorst & Dietz, 2008; Meschke & Baumoel, 2010). This normative approach, focusing strongly on the to-be situation, should ensure that both enterprise-level and local initiatives within the organization are consistent with the overall strategy, and enable a coherent and integrated development of business, information and IT. This directive function of EA targets not only managers as its users, but also business analysts, system analysts, software architects and other roles in projects (re)designing the business and its IT support. In this article, we focus mainly on this latter function, a prescriptive EA providing constraints and high-level solutions to which business and IT systems – and in particular the projects implementing them – should conform. Prescriptive EAs prove to be common in practice. One example is the Enterprise Architecture of a manufacturing company, which uses principles, policies and models to ensure that business and IT initiatives are consistent with the business strategy (Bruls et al., 2010). Another example is a national statistical institute’s architecture, consisting of principles and models to which projects much adhere in order to save costs and increase the quality of statistical products (Foorthuis & Brinkkemper, 2008). An EA’s norms or prescriptions are often applied in projects. Although EA typically focuses on the entire enterprise and compliance is indeed demanded at this level, in practice it is unrealistic for an entire organization to become EA-compliant at short notice. It can therefore be expected that conformance will be achieved incrementally at the local level, step by step – or rather, project by project (cf. Ross et al., 2006). However, philosophers have acknowledged for hundreds of years that, although compliance with ‘contracts’ might be better for the group as a whole and it might also be in an individual actor’s best interest to agree to contracts, it may not be in his interest to actually comply with them. In contractarian ethics this is one of the issues of the so-called compliance problem (cf. Gauthier, 1991; Hartman, 1996). Because of this potential conflict of interest, it should be tested whether actors actually conform to the contract. If we consider a specific project to be the actor, then an EA could be seen as the contract that needs to be complied with. In other words, although conformance is required for obtaining EA benefits, it cannot be expected to occur automatically (Boh & Yellin, 2007). This is especially relevant here as compliance with EA norms may be in the best interest of the organization as a whole, but not optimal per se to the local projects and departments that actually have to comply. Assessments should therefore be carried out at the level at which EA is applied, i.e., the project level. Testing at this level also allows for correcting noncompliant aspects, at least if it is performed while EA is being applied. Assessing projects on conformance is crucial, as a large survey study (n=293) has shown not only that project compliance with EA is positively associated with various strategic benefits, but also that the most important determinant of conformance is in fact conducting compliance assessments of projects (Foorthuis et al., 2010). Emmerich et al. (1999) define compliance in the context of IT projects as “the extent to which software developers have acted in accordance with the ‘practices’ set down in the standard.” Kim (2007) defines compliance in this context as “an accordance of corporate IT systems with predefined policies, procedures, standards, guidelines, specifications, or legislation.” In the context of EA we define compliance as corporate business and IT systems being in accordance with predefined Enterprise Architecture prescriptions. We will use the terms “compliance” and “conformance” interchangeably. Likewise, “assessing compliance” and “testing on conformance” are considered equivalent. A “project” in this article refers to the regular projects that need to comply with Enterprise Architecture, which, by and large, have a localized scope (e.g., delivering a new business process and related IT applications for a department). In this article, we aim to answer the following research question: 46 Journal of Database Management, 23(2), 44-71, April-June 2012 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. How can projects, and the business and IT solutions they deliver, be assessed on compliance with a prescriptive EA? To answer the main research question, we will divide it into several sub-questions: 1. What concepts play a key role in assessing compliance with EA? 2. By what process can EA compliance testing be carried out? 3. What kind of compliance checks can be utilized in the EA compliance test process, and what are their respective evaluation criteria? The underlying goal of our research is to identify and explore core aspects of testing projects on EA compliance. It is our intention to stimulate additional research into the topic. A second, more practical goal is that the results should provide organizations with a working model that can be used to develop their approach for testing their change initiatives on EA conformance. This article will proceed as follows. In the next section, related topics and work are discussed. Following that, we position our study in the context of EA and describe the research approach. The subsequent sections aim to find answers to the respective sub-questions and present our empirical case. The final section is for discussion and conclusions. RELATED TOPICS AND WORK Although we did not find any academic work dedicated to assessing compliance with EA at the time of our research, the topic can nonetheless be linked to other work. In particular, EA conformance testing is related to the fields of compliance management, software testing and auditing. In terms of compliance management, several areas relevant to our discussion can be acknowledged. First, due to legislation, organizations are required to comply with regulations that have consequences for their business processes and information systems. Non-compliance here may even have penal consequences for an organization’s management (El Kharbili et al., 2008). In Europe, important drivers are Directive 95/46/EC, i.e., the Data Protection Directive, and Directive 2002/58/EC, i.e., the Privacy and Electronic Communications Directive (Massacci et al., 2005; Nouwt, 2008). Examples of laws in the United States which demand compliance are the Sarbanes-Oxley Act, the Gramm-Leach-Bliley Act and the Health Insurance Portability and Accountability Act (Kim, 2007; Lankhorst, 2005; zur Muehlen et al., 2007). The Basel Accords, featuring regulations for capital adequacy of the banking sector, form an example of a global regulatory framework (Barr & Miller, 2006). A second area in compliance management is consistency with international and industrywide standards for processes and products, such as ISO 9001 for quality management and IEC 61508 for safety. There are several reasons for conforming to such best practices, for example clients or strategic partners demanding certification for assurance reasons, and using best practices to improve the organization’s processes and products. Conformance to standards is especially important in large and critical systems engineering projects in, e.g., the defense, aerospace and telecommunications sectors. See Emmerich et al. (1999), Pfleeger et al. (1994), and Chung et al. (2008) for more about compliance with standards. We will employ some of the concepts in these publications in our own research. A third relevant area is security and risk management, which aims to protect the organization’s assets, such as valuable information. Compliance here has an important role to play in preventing both deliberate and unintentional harm to the organization, e.g., by imposing access restrictions. See for example von Solms (2005), Drew (2007), and Vroom and von Solms (2004) for more on this topic. All three areas are relevant to our discussion, as an EA can feature constraints and high-level solutions based on any of the above. Needless to say, they are not mutually exclusive. Journal of Database Management, 23(2), 44-71, April-June 2012 47 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. For example, security and risk management are principal concerns of the Basel framework and of international standards such as ISO/